Various systems have been developed to protect data. For example, authentication and authorization policies are used to verify users and control access to particular resources. Authentication involves confirming the identity of a user. Once the identity of the user is confirmed by authentication, the authenticated user can proceed with certain actions according to authorization policies. For example, an authorization policy may grant the user certain privileges to access and/or change certain data.
In shared computing environments, protecting data can be particularly important since multiple people or groups of people may access the data. Examples of secret data in a shared computing environment include passwords, an administrative password for various applications (such as Oracle database administration password), pass-phrases for encryption keys and certificates, etc. In many instances, secret data must be shared with one or more individuals, such as IT professionals and administrators, and must be shared in a manner that maintains the integrity of the data.
One manner of transmitting secret data is to tell or “push” the secret data to each individual that should receive the secret data. This may be done by speaking with or calling the individual. Other approaches include writing the secret data on a note or e-mail. However, such methods are not effective since the person who is to be reached may not be available, it may be difficult to reach all of the people within a certain period of time, and the secret data can be delivered to or taken by an unauthorized person. Additionally, individuals who have the secret data may leave a company or change responsibilities but still retain the secret data. Additionally, with these conventional methods, there is no audit trail identifying who received the secret data and when the data was received. These known “push” methods, therefore, are not effective and are not efficient.
Referring to FIG. 1, certain other known methods involve using a directory server 10, which uses the Lightweight Directory Access Protocol (LDAP). A LDAP server 10 directs client requests 30 for data 22 to another server 20 that stores the data 22, which is then retrieved and provided to the user to satisfy the request. LDAP is an Internet protocol that e-mail and other programs used to look up information from a server 20. LDAP defines the language or protocol (X.500) that is used by client programs 30 to communicate with servers 20 using the LDAP server 10 as an index or directory to the requested data 22 in another server 20 or datastore or database. LDAP provides authorization and authentication policies that must be satisfied before a LDAP server 10 can be utilized. When a LDAP server receives a request from a client, the server responds to the client with a pointer to where the client can obtain more information. Further details regarding LDAP are not provided here since LDAP is well known in the art. However, as shown in FIG. 1, the LDAP server 10 is used as a directory and refers to another data store or other server 20 that actually stores the data 22. There is no central storage of secret data 22, and LDAP servers 10 are not used for actual data 22 storage. Further, a LDAP server 10 does not provide for centrally storing encrypted data.
Thus, known methods and systems do not store secret data 22 and administration policies to LDAP servers 10 and allow the data 22 to be retrieved directly from these servers 10. Instead, known systems store secret data 22 on other servers 20 and databases, thus presenting greater security risks since there is no central and controllable storage of secret data and access policies.
Accordingly, there exists a need for an improved method for protecting secret data within a shared computing environment. Secret data and administration policies should be securely stored in a central location on a directory server, and if the secret data is changed, the same protection measures should apply to access the changed secret data.